1. Field of the Invention
The present invention relates to computer graphics systems. More specifically, this invention is a facility for perforating the geometric processing of a view model, which is configured by an application program in a computer graphics system.
2. Background Information
In computer graphics systems, a view model defines operations to be performed on geometry to be rendered. The view model has a number of coordinate systems where application programs specify operations. For example, in some prior art systems, a three-dimensional view model typically defines four coordinate systems: Model Coordinates (MC), Global Model Coordinates (GMC), World Coordinates (WC), Virtual Device Coordinates (VDC), and Device Coordinates (DC). Each coordinate system is a convenient place to specify operations. For example, the application specifies geometry in MC, lights in WC, view clip planes in VDC, and a pick aperture in DC. A sequence of matrices transform geometry from coordinate system to coordinate system where operations such as lighting, view clipping, and picking are performed. The MC-to-WC mapping is called the model matrix and the WC-to-VDC mapping is called the view matrix. The model matrix, view matrix, lights, and view clip planes are all context attributes of the view model. Applications specify these to configure the view model.
The view model is conceptual in the sense that an implementation on a graphics device actually may perform an operation in a coordinate system other than the one where the application specifics it as long as the result is the same. Device pipelines do this for improved performance.
Prior art high performance graphics devices typically retain view model states such as matrices, lights, and clip planes. But they are more restrictive than the conceptual view model. For example, they typically require the MC-to-CC and CC-to-DC matrices (CC is Clipping Coordinates, which is not exposed at the application program interface [API] level), and lights in MC and LC (LC is Lighting Coordinates, which is not exposed at the API level). These items are derived from the API view model attributes. When an application changes an attribute, an item derived from that attribute becomes invalid. It must be recalculated, and the device must be informed of the change so that the device pipeline can reload the derived item into the device. In some prior art systems, when an application program sets a view model attribute in the context, all invalidated items are recalculated at the time of change to the attribute. This results in unnecessary calculations at every stage in the pipeline and consumes unnecessary system overhead because an application may change several view model attributes before sending a graphics primitive. Each attribute change results in a complete recalculation.
A graphics primitive is a function that takes geometry in MC, passes it through the geometry pipeline for transformation and clipping, and renders it in DC. An example of a primitive is polyline, which is an ordered set of vertices with each pair connected by a line segment. The polyline primitive takes at least two vertices in MC, transforms the vertices to CC, clips the polyline so that no geometry extends outside or the viewing rectangle, transforms the clipped vertices to DC, and renders the line segments between each pair of vertices.
Another example of a primitive is annotation text, which is a character string where each character is rendered with polylines. Font files hold a description of the polyline representation of each character. The annotation text primitive takes a character string and a reference point in MC and transforms the reference point to VDC. If the reference point is inside the viewing rectangle, it builds a polyline representation of the character string in VDC. It would be extremely convenient if a pipeline could send these polylines to the polyline primitive above so that the annotation primitive does not have to duplicate the remainder of the geometric pipeline and the entire rendering pipeline. Unfortunately, the text is in VDC now, and the polyline primitive expects geometry in MC. This poses a problem. Therefore, it would be desirable if a device interface would support entry of items from a variety of coordinate systems, as the device pipeline requires.
One prior art method of changing context and its effect on the graphics pipeline will now be discussed. This method will be known as "dumb evaluation" because the system does not account for subsequent changes to the specified or subsequent contexts prior to performing calculations. Using this prior art technique, first, an application may set view model attributes in context. Upon a detection of this change, the system will then store the values in memory and calculate nothing. Subsequent to this operation, the application may then call a graphics primitive, such as that requiring the rendering of an object. The geometry can then be passed to the device pipeline (DP), and the DP calculates "derived" items (those changing in subsequent view models due to the changes in the specified context) from view model attributes specified in the given context. The DP loads derived items into a device (sometimes a hardware graphics accelerator), and the DP sends the geometry to the device. The disadvantage of this technique is that if the view model attributes do not change between graphics primitives (a very common occurrence) then derived items are calculated and loaded unnecessarily into the device. These calculations reduce overall system performance.
A second prior art technique is known as "automatic evaluation." Using this technique, an application program can set a view model's attributes in a specified context, and those changes are stored into memory. Then, the derived items, may be recalculated from the view model attributes and they are stored into memory referenced by the context. Subsequent to these operations, the application program may call a graphics primitive. At this point, geometry is passed to the DP and the DP gets precalculated derived items (from the changes in context performed above) from the context and loads them into the device. Then, the DP sends the geometry to the device. The disadvantages of this technique are that if the application sets several view model attributes between graphics primitives (a not uncommon occurrence) then all derived items from the changes in contexts will be re-evaluated after each change to the view model. All calculations occurring before the last change to the view model thus are unnecessary. These extraneous calculations reduce overall graphics performance. Also, a DP may need only a small subset of the derived items supported for the given changes to the context(s).
Thus, prior art computer graphics systems suffer from numerous deficiencies.